<!DOCTYPE html>
<html lang="en">

<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Porting to GCC 5</title>
<link rel="stylesheet" type="text/css" href="https://gcc.gnu.org/gcc.css" />
</head>

<body>
<h1>Porting to GCC 5</h1>

<p>
The GCC 5 release series differs from previous GCC releases in
<a href="changes.html">a number of ways</a>. Some of
these are a result of bug fixing, and some old behaviors have been
intentionally changed in order to support new standards, or relaxed
in standards-conforming ways to facilitate compilation or run-time
performance.  Some of these changes are not visible to the naked eye
and will not cause problems when updating from older versions.
</p>

<p>
However, some of these changes are visible, and can cause grief to
users porting to GCC 5. This document is an effort to identify major
issues and provide clear solutions in a quick and easily searched
manner. Additions and suggestions for improvement are welcome.
</p>


<h2 id="cpp">Preprocessor issues</h2>

<p>The preprocessor started to emit line markers to properly distinguish
whether a macro token comes from a system header, or from a normal header
(see <a href="https://gcc.gnu.org/PR60723">PR60723</a>).
These new markers can cause intriguing problems for software not ready 
to handle them.  To stop the preprocessor from generating the <code>#line</code>
directives, use
<a href="https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html#Preprocessor-Options">the <code>-P</code> option</a>.</p>

<p>Consider the following snippet:</p>

<pre><code>
  #include &lt;stdlib.h&gt;
  exitfailure EXIT_FAILURE
</code></pre>

In the past "<code>gcc -E</code>" used to emit:

<pre><code>
# 2 "t.c" 2
exitfailure 1
</code></pre>

Current GCC emits:

<pre><code>
# 2 "t.c"
exitfailure 
# 2 "t.c" 3 4
           1
</code></pre>

Observe how the <code>exitfailure</code> and <code>1</code> tokens
are not on the same line anymore.


<h2 id="c">C language issues</h2>

<h3 id="gnu11">Default standard is now GNU11</h3>

<p>GCC defaults to <code>-std=gnu11</code> instead of <code>-std=gnu89</code>.
This brings several changes that users should be aware of.  The following
paragraphs describe some of these changes and suggest how to deal with them.
</p>

<p>Some users might prefer to stay with gnu89, in which case we suggest to
use the <code>-std=gnu89</code> command-line option, perhaps by putting it
in override <code>CFLAGS</code> or similarly in Makefiles.</p>

<p>To ease the migration process, GCC offers two new warning options,
<code>-Wc90-c99-compat</code> and <code>-Wc99-c11-compat</code>.  The
former warns about features not present in ISO C90, but present in ISO C99.
The latter warns about features not present in ISO C99, but present in
ISO C11.  See the GCC manual for more info.</p>

<h4 id="inline">Different semantics for inline functions</h4>

<p>While <code>-std=gnu89</code> employs the GNU89 inline semantics,
<code>-std=gnu11</code> uses the C99 inline semantics.  The C99 inline semantics
requires that if a function with external linkage is declared with
<code>inline</code> function specifier, it also has to be defined in the same
translation unit (TU).  Consequently, GCC now warns if it sees a TU
such as the following:</p>

<pre><code>
  inline int foo (void);
</code></pre>

<p>This example now gives the following diagnostic:</p>

<pre>
<b>f.c:1:12:</b> <span class="boldmagenta">warning:</span> inline function <b>'foo'</b> declared but never defined
   inline int foo (void);
              <span class="boldlime">^</span>
</pre>

<p>Furthermore, there is a difference between <code>extern inline</code> and
<code>inline</code>:</p>
<ul>
  <li>C99 <code>inline</code>: No externally visible function is generated.
      If the function is referenced in this TU, an external definition has to
      exist in another TU; same as GNU89 <code>extern inline</code> with no
      redefinition.</li>
  <li>C99 <code>extern inline</code>: An externally visible function is
      generated; same as GNU89 <code>inline</code>.</li>
  <li>GNU89 <code>inline</code>: Same as C99 <code>extern inline</code>.</li>
  <li>GNU89 <code>extern inline</code>: No externally visible function is
      generated; no equivalent in C99, because redefinition is not
      permitted.</li>
</ul>

(Fortunately <code>static inline</code> is the same in both C99 and GNU89.)

<p>In other words, ISO C99 requires that exactly one C source file has the
callable copy of the inline function.  Consider the following program:</p>

<pre><code>
  inline int
  foo (void)
  {
    return 42;
  }

  int
  main (void)
  {
    return foo ();
  }
</code></pre>

<p>The program above will not link with the C99 inline semantics, because no
out-of-line function <code>foo</code> is generated.  To fix this, either
mark the function <code>foo</code> as <code>extern</code>, or add the following
declaration:</p>

<pre><code>
  extern inline int foo (void);
</code></pre>

<p>This ensures that an externally visible function be emitted.
To enforce the GNU89 inline semantics, you can either use the
<code>-fgnu89-inline</code> command-line option, or mark a function with the
<code>gnu_inline</code> attribute.  For example:</p>

<pre><code>
  __attribute__ ((gnu_inline)) inline int
  foo (void)
  {
    return 42;
  }
</code></pre>

<p>A program which used GNU89 <code>extern inline</code> may fail in the new
standard due to multiple definition errors:</p>

<pre><code>
  extern inline int
  foo (void)
  {
    return 42;
  }

  int
  foo (void)
  {
    return 23;
  }

  int
  main (void)
  {
    return foo ();
  }
</code></pre>

<h4 id="default-warnings">Some warnings are enabled by default</h4>

<p>The C99 mode enables some warnings by default.  For instance, GCC warns
about missing declarations of functions:</p>

<pre><code>
  int
  foo (void)
  {
    return bar ();
  }
</code></pre>

<p>This example now gives the following diagnostic:</p>

<pre>
<b>w.c:4:10:</b> <span class="boldmagenta">warning:</span> implicit declaration of function <b>'bar'</b> [-Wimplicit-function-declaration]
   return bar ();
          <span class="boldlime">^</span>
</pre>

<p>To suppress this warning add the proper declaration:</p>

<pre><code>
  int bar (void);
</code></pre>

<p>or use <code>-Wno-implicit-function-declaration</code>.</p>

<p>Another warning that is now turned on by default is the warning about
implicit int, as in the following snippet:</p>

<pre><code>
  foo (u)
  {
    return u;
  }
</code></pre>

<p>This example now gives the following diagnostic:</p>

<pre>
<b>q.c:1:1:</b> <span class="boldmagenta">warning:</span> return type defaults to <b>'int'</b> [-Wimplicit-int]
   foo (u)
   <span class="boldlime">^</span>
<b>q.c:</b> In function <b>'foo'</b>:
<b>q.c:1:1:</b> <span class="boldmagenta">warning:</span> type of <b>'u'</b> defaults to <b>'int'</b> [-Wimplicit-int]
</pre>

<p>To suppress this warning just add the proper types:</p>

<pre><code>
  int
  foo (int u)
  {
    return u;
  }
</code></pre>

<p>or use <code>-Wno-implicit</code> or <code>-Wno-implicit-int</code>.</p>

<p>Another warning that is now turned on by default is the warning about
returning no value in a function returning non-void:</p>

<pre><code>
  int
  foo (void)
  {
    return;
  }
</code></pre>

<p>This example now gives the following diagnostic:</p>

<pre>
<b>q.c:4:3:</b> <span class="boldmagenta">warning:</span> <b>'return'</b> with no value, in function returning non-void
   return;
   <span class="boldlime">^</span>
</pre>

<p>The fix is either to specify a proper return value, or to declare the return
type of <code>foo</code> as <code>void</code>.</p>

<h4 id="complit">Initializing statics with compound literals</h4>

<p>Previously, initializing objects with static storage duration with compound
literals was only allowed in the GNU89 mode.  This restriction has been lifted
and currently it is possible to do this even in C99/C11 mode.  The following
snippet is an example of such initialization:</p>

<pre><code>
  struct T { int i; };
  struct S { struct T t; };
  static struct S s = (struct S) { .t = { 42 } };
</code></pre>

<p>We used to reject such code in C99/C11 mode:</p>

<pre>
<b>q.c:3:29:</b> <span class="boldred">error:</span> initializer element is not constant
   static struct S s = (struct S) { .t = { 42 } };
                               <span class="boldlime">^</span>
</pre>

<p>Note that using <code>-Wpedantic</code> will cause a warning be emitted:</p>

<pre>
<b>q.c:3:29:</b> <span class="boldmagenta">warning:</span> initializer element is not constant [-Wpedantic]
   static struct S s = (struct S) { .t = { 42 } };
                       <span class="boldlime">^</span>
</pre>

<h4 id="version-macro"><code>__STDC_VERSION__</code> macro</h4>

<p>As the default mode changed to C11, the <code>__STDC_VERSION__</code>
standard macro, introduced in C95, is now defined by default, and has
the value <code>201112L</code>.</p>

<p>Typically, this macro is used as in the following:</p>

<pre><code>
  #if !defined __STDC_VERSION__ || __STDC_VERSION__ &lt; 199901L
    /* ... */
  #else
  # include &lt;stdint.h&gt;
  #endif
</code></pre>

<p>You can check the macro using <code>gcc -dM -E -std=gnu11 - &lt; /dev/null | grep STDC_VER</code>.</p>

<h4 id="scanf">Different meaning of the <code>%a *scanf</code> conversion specification</h4>

<p>In C89, the GNU C library supports dynamic allocation via the <code>%as</code>,
<code>%aS</code>, and <code>%a[...]</code> conversion specifications; see
<a href="https://www.gnu.org/software/libc/manual/html_node/Dynamic-String-Input.html#Dynamic-String-Input">
this</a> for more info.
In C99, the <code>a</code> conversion specifier is a synonym for <code>f</code>
(float), so the compiler expects an argument of type <code>float *</code>.
This is a change in semantics, and in combination with the
<code>-Wformat</code> warning option the compiler may emit additional warnings:</p>

<pre><code>
  #include &lt;stdio.h&gt;

  int
  main (void)
  {
    char *s;
    scanf ("%as", &amp;s);
  }
</code></pre>

<pre>
<b>q.c:7:10:</b> <span class="boldmagenta">warning:</span> format <b>'%a'</b> expects argument of type <b>'float *'</b>, but argument 2 has type <b>'char **'</b> [-Wformat=]
  scanf ("%as", &amp;s);
         <span class="boldlime">^</span>
</pre>

<p>To use the dynamic allocation conversion specifier in C99 and C11, specify
<code>m</code> as a length modifier as per POSIX.1-2008.  That is, use
<code>%ms</code> or <code>%m[...]</code>.</p>

<h3 id="new-warnings">New warnings</h3>

<p>Several new warnings have been added to the C front end.  Among others
<code>-Wpedantic</code> now warns about non-standard predefined identifiers.
For instance:</p>

<pre><code>
  void
  foo (void)
  {
    const char *s = __FUNCTION__;
  }
</code></pre>

<pre>
<b>q.c:4:19:</b> <span class="boldmagenta">warning:</span> ISO C does not support <b>'__FUNCTION__'</b> predefined identifier [-Wpedantic]
  const char *s = __FUNCTION__;
                  <span class="boldlime">^</span>
</pre>

<p>The fix is either to use the standard predefined identifier <code>__func__</code>
(since C99), or to use the <code>__extension__</code> keyword:</p>

<pre><code>
  const char *s = __extension__ __FUNCTION__;
</code></pre>


<h2 id="cxx">C++ language issues</h2>

<h3 id="nullptr">Converting <code>std::nullptr_t</code> to <code>bool</code></h3>

<p>Converting <code>std::nullptr_t</code> to <code>bool</code> in C++11
mode now requires direct-initialization.  This has been changed in
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1423">DR 1423</a>.</p>

<p>As a consequence, the following is invalid:</p>

<pre><code>
  bool b = nullptr;
</code></pre>

<p>but the following is valid:</p>

<pre><code>
  bool b(nullptr);
</code></pre>

It is recommended to use the <code>false</code> keyword instead of
converting <code>nullptr</code> to <code>bool</code>.

<h3 id="dr1579">Return by converting move constructor</h3>

<p>GCC 5 implements
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579">DR 1579</a>
which means that when compiling a function like:</p>

<pre><code>
  X
  foo()
  {
    Y y;
    return y;
  }
</code></pre>

<p>GCC first attempts to construct the return value as though <code>y</code> 
were an rvalue, and if that fails then it tries again using an lvalue
(all C++11 compilers already do this when returning a variable of the
same type as the function returns, but now they are also required to do it
when the types are not the same).
This changes the constructor that gets called in some cases,
for example it might now call <code>X(Y&amp;&amp;)</code> instead of
<code>X(const Y&amp;)</code>.
</p>
<p>
In most cases the only observable difference is code that runs faster
(by moving instead of copying) but if it causes a problem the new behavior
can be prevented by ensuring the compiler treats <code>y</code> as an lvalue,
using <code>return X(y);</code> or
<code>return static_cast&lt;Y&amp;&gt;(y);</code>.
</p>


<h2 id="links">Links</h2>

<p>
Marek Polacek and Jakub Jelinek,
 <a href="https://lists.fedoraproject.org/pipermail/devel/2015-February/207549.html">Fedora test rebuild on x86_64-linux-gnu with gcc-5.0.0-0.5.fc22</a>
</p>

</body>
</html>
